Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1991/91-01

Text File | 1995-12-31 | 48KB | 1,584 lines

Path: ucivax!gateway
From: [e-mail] (robert s mcalister)
Subject: how do you trap an event in an INIT?
Message-ID: <[e-mail]>
X-Mailer: Elm [version 2.1 PL1]
Newsgroups: fa.think-c
Lines: 8
Date: 4 Jan 91 23:17:24 GMT


I am looking for some sample code on how to trap events
in an INIT.  I am trying to trap a disk insertion.
Thanks in advance.

Scott McAlister         [e-mail]
Clemson University











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Resorceror
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 7 Jan 91 17:16:50 GMT

>No more "Shall I create
>a resource fork?" nonsense.

Why is this nonsense? What does Resorcerer do instead? Create one
regardless? I'd rather have the warning.

Resorcerer sounds nice though, but it's expensive and probably totally
unobtainable outside the US. ResEdit 1.2 is neither.

Nick.










Path: ucivax!gateway
From: [e-mail] (Martijn Koster)
Subject: Crash in __msg after cancelling PickFileName...Why? Help!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 61
Date: 9 Jan 91 14:03:46 GMT

OK, I'm going mad...

I get crashes when sending a Dispose from my application to a document,
before the message actually gets there. The debugger was no help, so
I had a look with TMON, and found the problem is an address error in
__msg (in oops.c):

                lea     2(a5,d0.w),a1   ;  A1 ==> class record + 2
crash-->        move.w  (a1)+,d0        ;  D0.W = #methods - 1
         @2     move.w  (a1)+,d1        ;  D1.W = method ID

Why do I get this and what do I do about it? I'll explain what the app
does, and then describe the crash scenario.

My application is very simple indeed: it asks for a file, then asks
the user to pick a file name and copies the contents of the file into
the new one while performing some conversion on the data. So it doesn't
really have documents as such, but I did use the CDocument to divide up
this program.

Here's the architecture:

File:     Convert.c  ConvertApp.c         ConvertDoc.c
          ---------  ------------         ------------
Methods:  main       IConvertApp          IConvertDoc
                     SetUpFileParameters  NewFile
                     CreateDocument       OpenFile
                     OpenDocument         Dispose
This is what they do:
--------------------------------------------------------------------------
NewDocument()                           OpenDocument(SFReply *macReply)
{                                       {
   aDoc = new(ConvertDoc);                 aDoc = new(ConvertDoc);
   aDoc->IKvKConvertDoc(this);             aDoc->IKvKConvertDoc(this);
   aDoc->NewFile();                        aDoc->OpenFile(macReply);
   aDoc->Dispose();                        aDoc->Dispose();
}                                       }
--------------------------------------------------------------------------
OpenFile(macReply)              NewFile()
{                               {
   Open file                       gApplication->ChooseFile(&macSFReply);
   PickFileName(macReply)          if (macSFReply.good)
   if (! macReply->good)           OpenFile(&macSFReply);
       return;                  }
   Open file
   do the conversion
}
--------------------------------------------------------------------------

If I do Open, select a file and give a filename ->  OK
If at startup (NewFile) I select a file then cancel the PickFileName -> OK
If I do Open, select a filename and then cancel the PickFileName -> I get a
crash in __msg when it tries to do the Dispose.

First I got mysterious crashes straight after the PickFileName, now
I only get them when trying to dispose.

What is going on here?? No doubt it is my fault, but when it's not my
programming that crashes it's difficult to find out what you did wrong :-/

-- Martijn Koster










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Crash in __msg after cancelling PickFileName...Why? Help!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 9 Jan 91 16:21:45 GMT

>I get crashes when sending a Dispose from my application to a document,
>before the message actually gets there. The debugger was no help, so
>I had a look with TMON, and found the problem is an address error in
>__msg (in oops.c):

From the fragments of code you provide, it isn't easy to see what's
happening and how things are scoped.

My guess: you're doing a method call to an object that has been Disposed.
I've hit that one a number of times, and it often results in an address
error during the dispatch.

Use the THINK debugger, and just before the method dispatch, check the
sanity of the object whose method you're about to call.

>-- Martijn Koster

Nick.










Path: ucivax!gateway
From: [e-mail] ("aka the Devastater.  destruction, pillage....")
Subject: Getting back to Finder and Random Drawing
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 9 Jan 91 21:49:19 GMT

Hi!   If you know the answer to these two questions, could you
please reply?  Thanks!

1)  When a program crashes and I go into MacsBug, is there an
address I can jump to in order to get back to the Finder?  (when
running multiFinder)  Typing "es" doesn't always work.

2)  How do I draw to a window and have the effect take place
immediately instead of using InvalRect and collecting update
events?  I am using Think C 4.0.  I would like to have a
procedure draw something without having to call the Draw()
procedure in the Pane object.

Thanks again!
Chester Liu

[e-mail]












Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: Think C and Comm Toolbox
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 11 Jan 91 00:35:27 GMT

               Think C and Comm Toolbox
Can someone point me in the direction of the header files for the comm toolbox?
 I've already converted the ".o" file, but I was hoping that someone else had
already converted all the .h files.


Thanks--

Tom
[e-mail]












Path: ucivax!gateway
From: [e-mail] (Chris Chase)
Subject: Calling methods from a code resource?
Message-ID: <9101151908.AA18303@olympus>
Newsgroups: fa.think-c
Lines: 32
Date: 15 Jan 91 19:14:52 GMT

I have a question regarding TCL. Can methods defined in an application
be called from a code resource? For example, suppose I have a class
foo with method func defined in an application program. Can I create a
code resource that takes an instance of object foo as an argument and
call the method func? Of course the code resource would require the
prototype declaration for the class foo.

The TCL manual does not make clear how method calls are implemented
(there are only a few comments about a runtime dispatcher and direct
calls without making clear exactly what happens). So I don't know if
the
linker will allow me to do this in a code resource. It would seem that
the concept of an object should allow method calls in programs where
the the method is not defined by calling the method at runtime.

Could someone give me some insight into how the Think C compiler
implements method calls and if the above would work?

The reason that I would want to implement something like the above is
that it allows code resources to be added that extend an applications
abilities by accessing data and functions within the application
without having to have the application source and recompile it. (one
would only need the class declarations with documentation.)

As an aside, am I right to believe that there should be no problem in
accessing the instance variables for the object in the code resource?


Thank you in advance,
Chris Chase
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Kevin Michael Goldsmith)
Subject: Midi Questions
Message-ID: <8bYpb=[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 15 Jan 91 19:41:59 GMT

Does anyone have any info on the MIDI manager, or know where I can get
some?  Also, I have heard that it isn't that great.  Does anyone know
about the protocols that the opcode boxes use?  Are they in printer
events or what?

Thanks,
  Kevin Goldsmith
[e-mail]
[e-mail]

Disclaimer: Disclaimer, I don't need no stinkin disclaimer.










Path: ucivax!gateway
From: [e-mail] (Kevin Michael Goldsmith)
Subject: Bitmap questions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 15 Jan 91 19:47:24 GMT

I want to use off-screen bitmaps to speed up some graphics programs I am
working on.  Does anyone having clues on doing this, or even better,
some source code?

Thanks,
   Kevin Goldsmith
[e-mail]
[e-mail]

Disclaimer: Disclaimer, I don't need no stinkin disclaimer.










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Calling methods from a code resource?
Original-From: ech (Ned Horvath)
Lines: 54
Date: 15 Jan 91 22:55:35 GMT
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0152003520> of Tue Jan 15 19:14:52 GMT 1991
>To: att!ics.uci.edu!think-c
Content-Type: Text
Content-Length: 3044
Newsgroups: fa.think-c
Message-Version: 2
Email-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ech-752>
UA-Content-ID: <PMX-PC-2.01A-000144-pegasus1-ech-3357>

------------ Original Message -------------
I have a question regarding TCL. Can methods defined in an application
be called from a code resource? For example, suppose I have a class
foo with method func defined in an application program. Can I create a
code resource that takes an instance of object foo as an argument and
call the method func? Of course the code resource would require the
prototype declaration for the class foo.
...
Could someone give me some insight into how the Think C compiler
implements method calls and if the above would work?

The reason that I would want to implement something like the above is
that it allows code resources to be added that extend an applications
abilities by accessing data and functions within the application
without having to have the application source and recompile it...
-------------------------------------------
What you want to do is real hard unless you want to write some assembler
language.  If you're willing to do that, yes.

What you want to do is possible, but has to be done very carefully.  ThinkC
associates a type with an object by placing a 16-bit A5-relative offset at the
beginning of the object.  Adding the offset to A5 gives the address of the
dispatch table, which in turn maps message numbers into the jump table address
for the specific method.  The last entry in the dispatch table points to the
superclass dispatch table, which is how inherited methods are found.  To see
the (assembler) code that uses this structure, look at __msg() in oops.c among
your ThinkC library sources.

The problem is that the A5-relative offset that "defines" the type of the
object is not going to be the same for your code resource as it is for your
application, or for some other code resource.  Every project you link is, in
general, going to assign the dispatch-table offsets differently and the
message numbers differently.  Thus, although you can (by being cagy) find the
dispatch table for the object, you can't even guess at the appropriate message
number.  Oops (no pun intended).  What you can do for partial agreement is to
link the class implementation with both the code resource AND the app.  Then,
if your app passes an object to a code resource, the receiving code resource
has to KNOW what the object's type is in advance.  This allows the code
resource to call bless (object_reference, type), do its thing, then send it
back to the application (which has to bless it back).  Or, the code resource
has to remember the 16-bit magic offset, bless, use, then restore the 16-bit
magic offset used by the application.

Of course, if the app passes an object which is a member of a SUBCLASS, the
code resource won't know that, and won't have access to the specialized
methods of that class.  So you don't get the full notion of "polymorphism"
when you do this (and will probably introduce errors in the process).  In
short, the app and code resource have to agree, in advance, on the EXACT type
of the passed object.

Hope that helps.

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Brain in Neutral)
Subject: THINK C Gestalt interface
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 15 Jan 91 22:56:16 GMT

Anyone got the Gestalt codes laying around for use with THINK C?

Paul DuBois
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Midi Questions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 16 Jan 91 10:17:17 GMT

>Does anyone have any info on the MIDI manager, or know where I can get
>some?

The documentation and software comes from APDA. I recently posted my MIDI
Manager interface code to the list archive machine - the announcement went
out about a month ago on this list. Did nobody notice?

>Also, I have heard that it isn't that great.

From whom? I don't have any serious problems with it.

>Does anyone know
>about the protocols that the opcode boxes use?  Are they in printer
>events or what?

I don't know anything about the Opcode boxes. Which Opcode boxes? As far as
I know, they're all dumb interfaces (plus, perhaps, SMPTE h/ware).

I have, somewhere, the protocol specs. for MOTU's MIDI Time Piece, but the
info isn't presently of much use to MIDI Manager programmers.

Nick.










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re: Calling methods from a code resource?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 16 Jan 91 18:04:17 GMT


In principle, what you describe is correct, but there are two really big
caveats:

1) The Class ID (the 16-bit A5-relative offset to the class info proc's
jumptable entry) can (and often will) be different for different *compiles*,
let alone different projects.

2) The class ID will not always be a 16-bit A5-relative offset; to support
the large jumptable model, it'll be a 32-bit value which is fixed up at
runtime. Any externals which depend on it being a 16-bit offset will break.

It seems to me that the only surefire way to go is to support class
instantiation and message passing by name.

R.










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Problem with GetString? Or is it me?
Original-From: ech (Ned Horvath)
Lines: 34
Date: 18 Jan 91 18:06:17 GMT
Message-ID: <[e-mail]>
In-Reply-To: your message <attbl0180221360> of Thu Jan 17 13:18:00 EST 1991
>To: att!ics.uci.edu!think-c
Content-Type: Text
Content-Length: 1355
Newsgroups: fa.think-c
Message-Version: 2
Email-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ech-769>
UA-Content-ID: <PMX-PC-2.01A-000144-pegasus1-ech-3403>

------------ Original Message -------------
Ned:

My copy of Inside Mac claims that GetResource will load the resource
into memory if it isn't there already.  Why should I do an explicit
LoadResource, or is Inside Mac wrong in this case (it has been wrong in
a few others, so it might be...).

()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()
D. Jay Newman          !  That is not dead which can eternal lie
[e-mail]      !  And with strange eons even death can die
CBEL--Teaching and Learning Technologies Group
--------- End of Original Message ---------

I stand corrected: obviously I've been more paranoid than I need to be.

My experience is that IM rarely lies, and I expect you're correct.  No doubt
I've had problems in the past where I retained handles to purgeable resources,
and neglected to call LoadResource before use.

Notice that if SetResLoad (FALSE) has been called, GetResource DOES return a
handle to a NIL master pointer.  I have used a sequence like
        SetResLoad (FALSE);
        theHandle = Get1Resource (type, id);
        SetResLoad (TRUE);
to discover if the resource exists without actually loading it.  'theHandle'
remains valid even if the resource gets purged, and
        LoadResource (theHandle);
will 'do the right thing.'

Sorry to cause confusion.

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Mohammad Ibrahim Kilani)
Subject: Req. Sample Code for user interface
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 18 Jan 91 22:33:57 GMT

Hello every body!

I am looking for sample code in Think C that shows how to use QuickDraw
routines to perform simple drawing of geometric objects including
dragging and resizing.  Think C disk has a demo that shows how to do
paint funcions but does not allow dragging objects or resizing of drawn
objects.

Any hint to public or commercial source will be appreciated.










Path: ucivax!gateway
From: [e-mail] (SCHABTACH ADAM)
Subject: Drawing at interrupt time
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 19 Jan 91 21:17:30 GMT


Anyone know the best way to force a Pane to redraw its contents at interrupt
time? I need to change the contents of a Pane during an interrupt service
routine (for the MIDI Manager); I can't wait for an update event to redraw
it for me. This has to take place without colliding with other graphical
operations, since the user could be manipulating a control or causing other
drawing activity when the interrupt occurs.

Thanks in advance for any suggestions.

--Adam










Path: ucivax!gateway
From: [e-mail] (SCHABTACH ADAM)
Subject: Re:  Drawing at interrupt time
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 20 Jan 91 01:39:12 GMT


Thanks to Rich and Juri for pointing out to me that I simply can't do any
drawing at interrupt time, like it or not. I should've realized that;
maybe I've been programming too much recently. :-)

So much for my nifty animation. :-)

--Adam










Path: ucivax!gateway
From: [e-mail] (Marshall Rose)
Subject: Accessing QuickDraw globals from a DA
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 22 Jan 91 06:04:51 GMT

I'm now in the position of having to write a DA that needs access to a
couple of the QuickDraw globals (i.e., arrow and screenBits).

What is the cleanest way of doing this?  The THINK C manual suggests
using some inline assembly, but a brief example would go a long way
towards making things a lot clearer.

Thanks,

/mtr










Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: Accessing QuickDraw globals from a DA
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Marshall Rose" at Jan 22, 91 6:04 am
X-Mailer: ELM [version 2.3 PL2]
Newsgroups: fa.think-c
Lines: 28
Date: 22 Jan 91 08:10:31 GMT

Marshall Rose writes:
>
> I'm now in the position of having to write a DA that needs access to a
> couple of the QuickDraw globals (i.e., arrow and screenBits).
>
> What is the cleanest way of doing this?  The THINK C manual suggests
> using some inline assembly, but a brief example would go a long way
> towards making things a lot clearer.
>
I don't know how clear this is, but here's what I do:

I first #define CURRQDVAR as such:

(*(QDVarRecPtr)(*(long *)(CurrentA5) - (sizeof(QDVarRec) - sizeof(thePort))))

Then I refer to fields in it, for example:

CURR_QDVAR.gray

I think this all works.

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : [e-mail]
BITNET (if no other way) : FREE0285@UIUCVMD










Path: ucivax!gateway
From: [e-mail]
Subject: Questions About USing TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: j.a.brownlee
Lines: 36
Date: 22 Jan 91 13:07:37 GMT

Hi, folks.  Let me start off by saying thaty this mailing list is great.  I've
gotten a lot of useful tips and info from it.  Now down to business...

I have been using Think C for about 4 years now, but I just recently decided
to try using the TCL.  I have experience with AT&T C++ 2.0, so Think C's OOP
stuff is quite a change.  I am having a couple of problems that are probably
easily solved, and I have RTFM, but perhaps I missed something.  I am using
TC 4.0.2 under 6.0.3 on an 8MB IIcx.

I started by making a copy of the Starter Project.  Using the manual and the
comments in the code as a guide, I began filling in the functionality.  I am
having these problems so far, and I defer to you TCL Masters out there!

   .    I filled in CStarterPane::Draw() and my window draws fine when an
    update event comes along.  The problem is they don't seem to come
    along often enough.  How do I force one?  There is a Refresh() method
    in the CPane class, but when I make a change to my data, how do I
    call the method from an "alien" file?  Or should I just use good 'ol
    InvalRect() directly?

   .    I have my windows defined via ResEdit and using the #1234 scheme to
    set the command numbers.  The manual says I should handle as many
    commands as possible inside the CStarterDoc version of DoCommand().
    Still, sometimes I don't get a command indication when I select
    certain menu items.  They seem to be defined correctly.  Any hints?

   .    Any advice on what scheme to use to save my data into the file?  I
    generally have used fopen() and friends from the ANSI library in the
    past.  Can I/Should I still do this?

Thanks a 10^6, everyone!

   -      _   Joe Brownlee, Analysts International Corp. @ AT&T Network Systems
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail] ("Martin Minow, ML3-5/U26  22-Jan-1991 1128")
Subject: Problem with selection in a scroll panorama
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 454
Date: 22 Jan 91 18:19:05 GMT

You'll find attached a semi-working "ListManager" replacement class.
The list part works fine, but there's one tiny bug -- if you select
something, scroll the selection pane, then select something else,
hiliting gets very messed up.  I've stared at this until I'm blue
in the face, but haven't spotted the no-doubt trivial bug.  Eternal
gratitude to whoever discovers it first.

By the way, you're welcome to use this in your programs, but I retain
the copyright -- it might end up in a MacTutor article someday.

Martin Minow
[e-mail]
ps: I fiddled with formatting here and there -- don't be suprised
if there are minor syntax (etc) errors in this code.

---- ListSelector.h ----
/*
 * ListSelector
 *    SuperClass: CSelector
 *
 * Copyright 1991 Martin Minow.  All rights reserved.
 *
 * ListSelector mimics a (stripped-down)
 * Macintosh ListManager class.  It is limited to
 * a single "column" - though it can easily be
 * extended to multiple columns.  It borrows
 * heavily from several items in the "More Classes"
 * folder: CSelector (with code taken from
 * CGridSelector).
 *
 * The ListSelector consists of a ScrollPane
 * containing a CSelector Panorama and an
 * associated CList.
 *
 * You must override the DrawItem method.
 */
#define _H_ListSelector
#include <CScrollPane.h>
#include <CPanorama.h>
#include <CSelector.h>
#include <CList.h>

struct ListSelector : CSelector {
    CList        *itsList;
    long        itsDoubleClickCmd;

    void        IListSelector(
        CView        *anEnclosure,
        CBureaucrat        *aSupervisor,
        short        aWidth,
        short        aHeight,
        short        aHEncl,
        short        aVEncl,
        SizingOption    aHSizing,
        SizingOption    aVSizing,
        short        aCommandBase,
        long        aDoubleClickCmd,
        short        aBoxHeight
    );
    void        Dispose(void);
    void        DoDoubleClick(void);
    void        Draw(
        Rect        *area
    );
    void        DrawItem(    /* OVERRIDE */
        short        anItem,
        Rect        *area
    );
    void        Remove(
        CObject        *theObject
    );
    void        Append(
        CObject        *theObject
    );
    void        AdjustBounds(void);
    CObject        *NthItem(
        short        itemNo
    );
    long        GetNumItems(void);
    void        HiliteItem(
        short        theItem,
        HiliteState        state
    );
    short        FindItem(
        Point        hitPt
    );
    void        FindItemBox(
        short        anItem,
        Rect        *itemBox
    );
    void        PaneToPanorama(
        Point        *hitPt
    );
    void        PanoramaToPaneR(
        Rect        *theRect
    );
    void        PanoramaToPane(
        Point        *thePt
    );
};
------ ListSelector.c ----
/*
 * ListSelector
 *    SuperClass:    CSelector
 *
 * Copyright 1991 Martin Minow.  All rights reserved.
 *
 */
#include "ListSelector.h"
#include <CBorder.h>

/*
 * IListSelector
 * Create the list.  Parameters mostly follow CScrollPane.
 * The additional parameters are:
 *    aCommandBase    See MoreClasses: CSelector
 *    aDoubleClickCmd    Passed to the supervisor on double-clicks.
 *    aBoxHeight    Height of each cell in pixels.
 * When you layout your list, make sure you leave
 * room for a boarder.  I.e., if each cell is 10 pixels tall, and
 * you want 5 cells on the screenn aHeight should be (10 * 5) + 2.
 */
void
ListSelector::IListSelector(
    CView        *anEnclosure,
    CBureaucrat    *aSupervisor,
    short        aWidth,
    short        aHeight,
    short        aHEncl,
    short        aVEncl,
    SizingOption    aHSizing,
    SizingOption    aVSizing,
    short        aCommandBase,
    long        aDoubleClickCmd,
    short        aBoxHeight
    )
{
    CScrollPane    *aScrollPane;
    CBorder        *aBorder;
    Rect        theBox;

    aScrollPane = new(CScrollPane);
    aScrollPane->IScrollPane(
        anEnclosure,
        aSupervisor,
        aWidth,
        aHeight,
        aHEncl,
        aVEncl,
        aHSizing,
        aVSizing,
        FALSE,        /* No horizontal scroll    */
        TRUE,        /* Vertical scroll    */
        FALSE        /* No Size box        */
    );
    /*
     * Create the boarder, adjusting it so it lines
     * up with the scroll bar.
     */
    aBorder = new(CBorder);
    aBorder->IBorder(
        aScrollPane,
        aSupervisor,
        1, 1, 0, 0,
        sizELASTIC,
        sizELASTIC
    );
    aBorder->FitToEnclosure(TRUE, TRUE);
    SetRect(&theBox, -1, -1, 1, 0);
    aBorder->ChangeSize(&theBox, FALSE);
    aBorder->SetWantsClicks(TRUE);
    /*
     * Create the Selector within the boarder.
     */
    inherited::ISelector(
        aBorder,
        aSupervisor,
        1, 1, 0, 0,    /* Dummy shape param's    */
        sizELASTIC,
        sizELASTIC,
        0,        /* No items yet        */
        NOTHING,    /* No item selected yet    */
        aCommandBase
    );
    itsDoubleClickCmd = aDoubleClickCmd;
    FitToEnclosure(TRUE, TRUE);
    /*
     * Connect the Panorama parts together.
     */
    SetScrollPane(aScrollPane);
    itsScrollPane->InstallPanorama(this);
    SetScales(aWidth, aBoxHeight);
    itsList = new(CList);
    itsList->IList();
}

/*
 * Dispose
 * Dispose of the list.  The Boarder, ScrollPane, and
 * Selector are disposed of automatically (I hope).
 */
void
ListSelector::Dispose()
{
    itsList->Dispose();
    inherited::Dispose();
}

/*
 * DoDoubleClick
 * Pass a double-click to the supervisor.
 */
void
ListSelector::DoDoubleClick()
{
    itsSupervisor->DoCommand(itsDoubleClickCmd);
}

/*
 * Draw
 * ** Is this causing the multiple-hilight problem? **
 */
void
ListSelector::Draw(
    Rect    *area
    )
{
    int        i;
    Rect        theBox;

    for (i = 1; i <= numItems; i++) {
        FindItemBox(i, &theBox);
        DrawItem(i, &theBox);
    }
    if (active)
        HiliteItem(selection, hiliteON);
}

/*
 * DrawItem
 * Draw a single item in this location.
 * Your ListSelector sub-class must override this
 * to draw the list contents.
 */
void
ListSelector::DrawItem(        /* OVERRIDE    */
    short    anItem,
    Rect    *area
    )
{
#if 0
    /*
     * Sample DrawItem -- a StringObject is
     * an object that holds a StringHandle.
     */
    StringObject        *aString;
    StringHandle        theDatum;
    FontInfo        info;
    SignedByte        handleState;

    aString = (StringObject *) NthItem(anItem);
    if (aString != NULL) {
        theDatum = aString->GetStringHandle();
        if (theDatum != NULL) {
        GetFontInfo(&info);
        MoveTo(
            area->left + 2,
            area->top + info.ascent
        );
        handleState = HGetState((Handle) theDatum);
        HLock((Handle) theDatum);
        DrawString(*theDatum);
        HSetState((Handle) theDatum, handleState);
        }
    }
#endif
}

/*
 * List Methods.  These could easily be extended
 * to allow more ListManager capability.  They don't do
 * much more than call the CList and fiddle the
 * Selector extent.
 *
 */
void
ListSelector::Remove(
    CObject    *theObject
    )
{
    itsList->Remove(theObject);
    --numItems;
    AdjustBounds();
}

void
ListSelector::Append(
    CObject    *theObject
    )
{
    itsList->Append(theObject);
    numItems++;
    AdjustBounds();
}

void
ListSelector::AdjustBounds()
{
    Rect        bounds;

    GetBounds(&bounds);
    bounds.bottom = bounds.top + GetNumItems();
    SetBounds(&bounds);
}

CObject *
ListSelector::NthItem(
    short        itemNo
    )
{
    return (itsList->NthItem(itemNo));
}

long
ListSelector::GetNumItems()
{
    return (itsList->GetNumItems());
}

/*
 * HiliteItem is taken more-or-less from
 * CGridSelector.
 */
void
ListSelector::HiliteItem(
    short    theItem,
    HiliteState    state
    )
{
    Rect        itemBox;
    long        ticks;

    if (theItem == NOTHING)
        return;
    FindItemBox(theItem, &itemBox);
    Prepare();
    switch (state) {
    case hiliteON:
    case hiliteOFF:
        HiliteMode &= ~(1 << hiliteBit);    /* IM V-62    */
        InvertRect(&itemBox);
        break;
    case hiliteDYNAMIC:
        PenNormal();
        PenMode(patXor);
        FrameRect(&itemBox);
        Delay(2, &ticks);
        InsetRect(&itemBox, 1, 1);
        FrameRect(&itemBox);
        Delay(2, &ticks);
        InsetRect(&itemBox, -1, -1);
        FrameRect(&itemBox);
        PenNormal();
        break;
    }
}

/*
 * Determine the item covered by hitPt.
 * Return NOTHING if nothing is specified.
 * hitPt is in Pane coordinates.
 */
short
ListSelector::FindItem(
    Point    hitPt
    )
{
    register short    itemNo;

    PaneToPanorama(&hitPt);
    itemNo = hitPt.v + 1;
    if (itemNo < 1 || itemNo > GetNumItems())
        return (NOTHING);
    else {
        return (itemNo);
    }
}

/*
 * Given an item number, find the Pane coordinates
 * that enclose this item.
 */
void
ListSelector::FindItemBox(
    short    anItem,
    Rect    *itemBox
    )
{
    SetRect(itemBox, 0, anItem - 1, 1, anItem);
    PanoramaToPaneR(itemBox);
}

/*
 * Convert a Point from Prame coordinates to Panorama
 * units -- this should be a CPanorama method.
 */
void
ListSelector::PaneToPanorama(
    Point    *hitPt
    )
{
    short    theHScale, theVScale;
    Point    thePosition;

    GetScales(&theHScale, &theVScale);
    GetPosition(&thePosition);
    hitPt->h /= theHScale;
    hitPt->h += thePosition.h;
    hitPt->v /= theVScale;
    hitPt->v += thePosition.v;
}

/*
 * Convert a Rect from Panorama units to Pane units.
 */
void
ListSelector::PanoramaToPaneR(
    Rect    *theRect
    )
{
    PanoramaToPane(&topLeft(*theRect));
    PanoramaToPane(&botRight(*theRect));
}

/*
 * Convert a Point from Panorama units to Pane units.
 */
void
ListSelector::PanoramaToPane(
    Point    *thePt
    )
{
    short    theHScale, theVScale;
    Point    thePosition;

    GetScales(&theHScale, &theVScale);
    GetPosition(&thePosition);
    thePt->h -= thePosition.h;
    thePt->h *= theHScale;
    thePt->v -= thePosition.v;
    thePt->v *= theVScale;
}

----- end -----










Path: ucivax!gateway
From: [e-mail] (Marshall Rose)
Subject: Re: Accessing QuickDraw globals from a DA
Message-ID: <[e-mail]>
In-Reply-To: Your message of Tue, 22 Jan 91 02:07:58 -0600.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 22 Jan 91 19:56:59 GMT

Thanks.  Since I can't find QDVarRec in the #include files, I suppose
one should define it as

    typedef struct QDVarRec {
        GrafPtr    thePort;
        Pattern    white;
        Pattern    black;
        Pattern    gray;
        Pattern    ltGray;
        Pattern    dkGray;
        Cursor    arrow;
        BitMap    screenBits;
        long    randSeed;
    }    QDVarRec, *QDVarRecPtr;

/mtr











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Drawing at interrupt time
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 22 Jan 91 20:24:01 GMT

>Anyone know the best way to force a Pane to redraw its contents at interrupt
>time? I need to change the contents of a Pane during an interrupt service
>routine (for the MIDI Manager); I can't wait for an update event to redraw
>it for me. This has to take place without colliding with other graphical
>operations, since the user could be manipulating a control or causing other
>drawing activity when the interrupt occurs.

Hi Adam,
   Suggestion #1 - don't do it. If you need to to graphics out of the event
loop (e.g. during a MouseDown() run), then I suggest you do nothing more
adventurous than having the interrupt routine set a global semaphore and
having your spin-wait in the drag routine look at it and do the drawing if
required.

You could perhaps do graphics directly by writing into the on-screen
bitmap, but this will screw things like CloseView (and window overlaps),
and probably be extraordinarily messy when dealing with multi-plane colour.

Don't cross the streams...

Nick.










Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: CommToolbox and Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 22 Jan 91 22:43:36 GMT

               CommToolbox and Think C
Does anybody anywhere have a copy of the CommToolbox header files converted to
Think C?

Thanks---

Tom
[e-mail]












Path: ucivax!gateway
From: [e-mail] (Sylvia-Kay Isler)
Subject: MacDraw Object Selection: How does it work?
Message-ID: <[e-mail]>
Posted-Date: Wed, 23 Jan 91 23:08:35 EST
Newsgroups: fa.think-c
Lines: 14
Date: 24 Jan 91 05:02:11 GMT


Hi,

I am writing a MacDraw-like application in which I would like to allow
the user to select objects by merely clicking the mouse on a given
object.

Does anyone out there know how MacDraw does this or have any suggestions
about the correct data structure and methods for allowing the user
to select objects by clicking?

Thanks,

Sylvia










Path: ucivax!gateway
From: [e-mail]
Subject: Can new() fail?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: j.a.brownlee
Lines: 32
Date: 24 Jan 91 17:02:44 GMT

Another question about Think C's OOP extensions.  I have been having a strange
problem creating some objects with new().  You know, one of those fun ones
where when you add debug, it vanishes!

According to the manual, the new() function takes a Class type argument and
returns a Handle for the object (remember, the OOP stuff does a "free"
dereference for you):

    myObj = ((ObjType *)new(ObjType));

My question is: can this fail and return a NIL pointer?  Presumably, this is
implemented via NewPtr() and can fail.  The manual suggests that you should
tack your Init() method call onto the above, with Init() returning "this":

    myObj = ((ObjType *)new(ObjType))->Init();

...but what if the returned Handle is NIL?  Bomb city!

My problem was a result of some code like the above that allocates space for
a 32x32 matrix of objects.  Somehow, though myObj[9][28] was not == 0L, if I
checked on the next line, object [9][28]'s Handle was == 0L!  That object and
only that object's handle was somehow toasted!  When I moved the Init() call
to a seprate line after cheking to see if myObj[][] is 0L, the problem
vanished.

Has anyone had a similar problem?  How does everyone do error checking on
Handles allocated via new()?  Any advice?

   -      _   Joe Brownlee, Analysts International Corp. @ AT&T Network Systems
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail] ("R. Mark Fleming")
Subject: re: MacDraw type Objects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 24 Jan 91 18:59:13 GMT

Objects are stored in a link list.  Grouped object are also stored in the
same list, where the Group Object point's to another list of the objects
grouped. Ungrouping objects you merge the sub list into the current list.

ie.
          <Text obj.> -> <Line Obj.> -> <Group Object> -> <line obj.>  -> nil
                                           |
                                           |
                                           +-> <line obj> -> <Rect Obj.> -> nil

This also controls which object is infront of which object.
Move Forward, Move Back, Move to Front, Move to Back all just reorder the list.


Hope this helps,
Mark Fleming
<<<<<<<<<<<<<<<=========================================>>>>>>>>>>>>>>>>>
Mark Fleming, Macintosh Support, Office Systems, Computing  & Communicat.
Services, Queen's University at Kingston, Phone: [phone]
Bitnet: FLEMINGM@QUCDN  or  [e-mail]    AppleLink: CDA0448
<<<<<<<<<<<<<<<=========================================>>>>>>>>>>>>>>>>>










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Can new() fail?
Original-From: ech (Ned Horvath)
Lines: 50
Date: 25 Jan 91 20:07:21 GMT
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0242029580> of Thu Jan 24 17:02:44 GMT 1991
>To: att!ics.uci.edu!think-c
Content-Type: Text
Content-Length: 2195
Newsgroups: fa.think-c
Message-Version: 2
Email-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ech-780>
UA-Content-ID: <PMX-PC-2.01A-000144-pegasus1-ech-3479>

> According to the manual, the new() function takes a Class type argument and
> returns a Handle for the object (remember, the OOP stuff does a "free"
> dereference for you):
>
>       myObj = ((ObjType *)new(ObjType));
>
> My question is: can this fail and return a NIL pointer?  Presumably, this is
> implemented via NewPtr() and can fail.

Yes, new() can return NIL.  Yes, you should check for it.  However, if you're
using the TCL, in particular CApplication, then you can afford to be a bit
less vigilant about checking every new() result.  For more details, read the
section "Memory management methods" under CApplication, Think C 4.0 manual, p.
234.

> ...The manual suggests that you should
> tack your Init() method call onto the above, with Init() returning "this":
>
>       myObj = ((ObjType *)new(ObjType))->Init();
>
> ...but what if the returned Handle is NIL?  Bomb city!

You have two potential problems here.  Yes, you're dead if new returns nil,
but in fact the out-of-memory handling (at least in CApplications, see above)
will have already either freed enough memory to let the new() succeed, or will
have taken a longjmp to the top of your event loop, or will have taken the
app down, so in practice the call to the Init method never happens (it could
happen in a DRVR or code resource, where there's much less help for low memory
conditions).  If you're designing a class you hope to use in non-apps, it's
best to be vigilant.

The other problem is that you are assigning the value returned by Init(), not
the value returned by new().  So your Init procedure above had better be
declared
        ObjType * ObjType::Init (void)
and EVERY path through it has to end with either
        return this;    /* you must do this explicitly */
or
        return NIL;
Most of the TCL initializations return NIL, and to get the one-liner you're
looking for, you need something like
        (myObj = (ObjType *)new(ObjType))->Init();
        ^                               ^
Note the parens that assign the result of new(), and THEN use that reference
to invoke the Init() method.  Now Init() can return anything, including void.

Hope that helps.

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Gestalt interface
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 24
Date: 27 Jan 91 19:36:29 GMT
Phone: [phone]

Date: Fri, 25 Jan 91 15:33:52 est
From: Phil Shapiro <[e-mail]>
Subject: THINK C Gestalt interface

Here's a binhex'd Compactor archive of the files needed to use the
Gestalt Manager and Sound Input Manager with THINK C v4.0.  These
files are converted versions of the files Apple has released to let
programmers take advantage of these new features in System 6.0.7 and
System 7.0bX.

These files are the official conversions of the interfaces.  Since
they are based on interim technical documentation, they are not
guaranteed to work in later system versions.  The next major release
of THINK C will include final versions of these files.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]

---------------- Gestalt_6.0.7Glue.cpt.hqx ----------------

[saved as: /mac/think-c/compiler/gestalt.hqx; 20K]










Path: ucivax!gateway
From: [e-mail] (Eric Yiskis)
Subject: Getting started with appletalk
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 28 Jan 91 17:06:00 GMT


What is the best way to get started with appletalk?  The Inside mac
documentation is kind of a mess and it doesn't even cover how
to access the ADSP protocol... Any suggestions?

- Eric Yiskis
([e-mail])










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Need QuickDraw help for FrameRect & FrameArc
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 48
Date: 29 Jan 91 05:20:45 GMT

I am using QuickDraw calls into a PicHandle to draw in a subclass of
Pane in TCL. I am being driven batty by two QuickDraw related problems.
First, I am trying to draw the frame of arcs which are bounded by
perfectly square arcRects. I know that you don't get the radii frame'd
by FrameArc(), so I am trying to mimic this by something like:

penSize = 1;
PenSize( penSize, penSize );
/* Frame the piece of the pie */
FrameArc(&arcRect, startAngle, arcAngle);
/* draw borders of wedges */
MoveTo( center.h, center.v  );
Line(     (int) (radius *  sin(startAngle * DegToRad) + 0.5 - penSize ),
                         (int) (radius * -cos(startAngle * DegToRad) + 0.5 - penSize ) );
MoveTo( center.h, center.v  );
endAngle = startAngle + arcAngle;
Line(     (int) (radius *  sin(endAngle * DegToRad) + 0.5 - penSize ),
                         (int) (radius * -cos(endAngle * DegToRad) + 0.5 - penSize )  );

The result is close, but not perfect. Is there a way to get the point of
intersection of the radius and the arc from which I could draw to the
center? Or is this one of those things resulting from using integer
coordinate systems>

Second, during the routine in which I am drawing the arcs, I start off
by drawing a circle around everything that is plotted, e.g.,

    /* draw circle surrounding the plot */
    circleRect = plotRect;
    InsetRect( &circleRect, 4, 4 );
    FrameArc( &circleRect, 0, 360 );

I am writing all this into a PicHandle which is HLock'ed after the
initial call to OpenPicture(). One of the calls is to FrameArc( &anArc,
0, 360 ) which produces a circle nicely in the window in which my pane
resides. I go to save this file as a PICT file via CPictFile by handing
off the PicHandle. This works just fine, except that when I open the
file with Canvas, the circle is the only thing that doesn't show up on
the screen. It IS there, because I can select it and fill it with a
pattern, but there is no associated pen size of 1 for the FRAME. What
gives?

Thanks in advance,

Cheers,
David McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Greg Stein)
Subject: Re: Need QuickDraw help for FrameRect & FrameArc
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 76
Date: 29 Jan 91 12:44:11 GMT

Here are a couple quick things to try:

Problem #1:

Try using AngleToPoint() (sp?) to convert your angle to something you
can use.  Quickdraw might be calculating the sin/cos a little bit
differently.


Problem #2:

Don't lock the PicHandle.  Quickdraw needs to be able to resize the
handle as it draws the picture.  When you lock it, the memory manager
might not be able to resize it correctly.  My guess is that Quickdraw
went ahead and drew the circle, but didn't add it to your PicHandle
since it couldn't be resized.

Greg Stein
Arpa: [e-mail]
UUCP: ..!{uunet,apple}!oracle!gstein


---- Included Message ----
From: "David S. McCormick" <[e-mail]>
Newsgroups: fa.think-c
Date: 29 Jan 91 05:20:45 GMT

I am using QuickDraw calls into a PicHandle to draw in a subclass of
Pane in TCL. I am being driven batty by two QuickDraw related problems.
First, I am trying to draw the frame of arcs which are bounded by
perfectly square arcRects. I know that you don't get the radii frame'd
by FrameArc(), so I am trying to mimic this by something like:

penSize = 1;
PenSize( penSize, penSize );
/* Frame the piece of the pie */
FrameArc(&arcRect, startAngle, arcAngle);
/* draw borders of wedges */
MoveTo( center.h, center.v  );
Line(     (int) (radius *  sin(startAngle * DegToRad) + 0.5 - penSize ),
                         (int) (radius * -cos(startAngle * DegToRad) + 0.5 - penSize ) );
MoveTo( center.h, center.v  );
endAngle = startAngle + arcAngle;
Line(     (int) (radius *  sin(endAngle * DegToRad) + 0.5 - penSize ),
                         (int) (radius * -cos(endAngle * DegToRad) + 0.5 - penSize )  );

The result is close, but not perfect. Is there a way to get the point of
intersection of the radius and the arc from which I could draw to the
center? Or is this one of those things resulting from using integer
coordinate systems>

Second, during the routine in which I am drawing the arcs, I start off
by drawing a circle around everything that is plotted, e.g.,

    /* draw circle surrounding the plot */
    circleRect = plotRect;
    InsetRect( &circleRect, 4, 4 );
    FrameArc( &circleRect, 0, 360 );

I am writing all this into a PicHandle which is HLock'ed after the
initial call to OpenPicture(). One of the calls is to FrameArc( &anArc,
0, 360 ) which produces a circle nicely in the window in which my pane
resides. I go to save this file as a PICT file via CPictFile by handing
off the PicHandle. This works just fine, except that when I open the
file with Canvas, the circle is the only thing that doesn't show up on
the screen. It IS there, because I can select it and fill it with a
pattern, but there is no associated pen size of 1 for the FRAME. What
gives?

Thanks in advance,

Cheers,
David McCormick
MIT-EAPS Geology
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: CommToolbox
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 29 Jan 91 20:10:21 GMT

               CommToolbox
Has anyone done a CommToolbox class yet?  I'm afraid that I don't understand it
well enough yet to do it myself, but if nobody else has, I guess I'll have to
jump in with both feet.


Thanks-

Tom
[e-mail]












Path: ucivax!gateway
From: [e-mail] (Thomas Lunde)
Subject: Drop me
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 30 Jan 91 02:39:34 GMT


Please remove my address from the Think-C mailing list.  Thank you.

Thomas Lunde

[e-mail]